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I.  INTRODUCTION 


A.  PURPOSE  OF  THE  THESIS 

The  Internet  has  seen  exponential  growth  since  1995  when  the  Internet 
became  commercialized  (Rutkowski,  1997).  This  commercialization  has  brought 
about  opportunities  for  enhanced  capabilities  influencing  many  activities  by  the 
ability  to  access  information.  The  World  Wide  Web  (WWW),  an  application  of 
the  Internet,  created  a  way  to  use  hyperlinks  to  visually  tap  the  Internet  tech¬ 
nology.  The  WWW  allowed  computer  lay  people  to  understand  how  the  Internet 
could  benefit  them  in  everyday  life  through  its  intuitive  use  of  icons.  "The  WWW 
created  a  social  turning  point  for  networking  equivalent  to  the  transition  seen  in  the 
automobile  industry  when  the  Model-T  automobile  was  produced."  (Buddenberg, 
1997)  The  Internet  was  no  longer  in  the  realm  of  the  technically  inclined  and 
computer  savvy.  Greater  usage  of  the  Internet  has  resulted  in  business  being  able 
to  tap  untold  markets,  increase  revenues,  and  increase  profits.  Greater  usage  has 
also  resulted  in  lower  unit  costs  for  access.  Reduced  costs  of  operating  networks 
benefits  the  owners  of  the  networks  by  making  it  cheaper  for  them  to  operate  and 
by  affording  them  greater  resources  to  invest  in  enhancements  and  upgrades  to 
meet  and  exceed  user  expectations. 
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Commercialization  of  the  Internet  did  not  occur  until  26  years  after  the 
ARPANET,  the  precursor  of  the  Internet,  was  launched  as  marked  by  the  first  four 
hosts  of  the  network  working.  Many  people  and  organizations  that  are  users  of  the 
Internet  today  did  not  have  expectations  until  the  last  two  years  of  how  they  would 
benefit  from  access  to  the  Internet.  Users  expectations  have  grown  well  after  the 
base  technology  matured.  Most  users  did  not  have  expectation  nor  quite  frankly 
could  anyone  predict  how  quickly  the  growth  of  the  Internet  occurred.  But,  this 
growth  in  usage  is  predominantly  limited  to  those  users  with  access  to  land  based 
Internet  connectivity  either  through  the  telephone  system  or  through  the  terrestrial 
mobile  cellular  system.  There  are  many  potential  users  that  either  operate  in 
remote  areas  without  access  to  this  land  based  Internet  connectivity  or  that  want 
the  flexibility  that  a  space  or  air  wave  based  wireless  infrastructure  would  provide. 
A  similar  expansion  in  usage  of  space  and  air  wave  based  media  like  the  expansion 
of  the  land  based  media  is  imminent  (Kappel,  1997).  Potential  users  are  beginning 
to  demand  access  to  the  same  capabilities  that  the  land  based  infrastructure 
supports.  Users  have  expectations  of  using  new  technology  immediately  after  that 
new  technological  idea  is  conceived  and  well  before  the  technology  is  mature. 

One  of  these  of  users  is  the  Oceanographic  Research  Fleet.  They  want  the 
capability  to  access  WWW  resources  through  the  Internet  while  afloat  to  assist, 
speed,  integrate,  and  coordinate  their  research  (Kappel,  1 997).  This  not  for  profit 


organization  is  acting  as  a  proof  of  concept  test  bed  for  the  SEANET  project. 
This  SEANET  project  is  a  collaborative  effort  designed  to  foster  remote  wireless 
connectivity  toward  the  end  of  meeting  the  Oceanographic  Research  Fleets 
demands.  They  represent  any  number  of  groups  or  individual  users  that,  once 
concepts  are  proven  and  infrastructure  is  established,  would  benefit  from  Internet 
access  at  remote  and/or  mobile  sites  not  supported  by  the  present  land  based 
system.  This  author  will  examine  how  the  SEANET  project  can  achieve  its  goals 
of  expanding  service  more  effectively  thereby  meeting  users  expectations. 

B.  SCOPE 

The  scope  of  this  thesis  will  include:  (1)  a  review  of  how  the  land  based 
Internet  expanded,  (2)  a  description  of  the  SEANET  project  as  representative  of 
any  user  in  remote  areas  not  supported  by  wired  Internet  access,  (3)  identification 
of  the  communications  resources,  infrastructure,  and  technology  needed  to  provide 
remote  wireless  Internet  access,  and  (4)  a  recommended  plan  for  more  effectively 
expanding  availability  of  remote  access  to  users  demanding  access. 

C.  METHODOLOGY 

This  research  will  entail  conducting  a  review  of  the  ARPANET  to  Internet 
expansion  to  gather  lessons  learned  that  can  be  applied  to  the  SEANET  project. 
This  research  will  the  provide  an  overview  of  the  system  that  SEANET  represents 
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that  provide  remote  access  and  identify  emerging  capabilities  that  SEANET  can 
leverage  to  more  quickly  support  their  users.  This  research  will  describe 
techniques  for  more  effectively  expanding  remote  Internet  access  that  will  benefit 
the  SEANET  project.  Finally,  this  research  will  propose  a  project  management 
plan  to  provide  the  controls  necessary  to  ensure  the  SEANET  project  meets  it 
objectives  on  time. 
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II.  REVIEW  OF  THE  ARPANET  TO  INTERNET  EXPANSION 


A.  INTRODUCTION  OF  THE  INTERNET  EVOLUTION 

In  order  to  understand  how  a  space  or  air-wave  based  (wireless)  Internet  can 
evolve,  it  is  useful  to  examine  the  evolution  of  the  terrestrial  Internet.  This  will 
provide  an  appreciation  of  the  strategies  used  to  develop  the  terrestrial  Internet  and 
provide  lessons  learned  from  that  process.  If  applicable,  these  strategies  and 
lessons  learned  will  better  allow  the  SEANET  project  to  meet  its  goals.  By 
tailoring  strategies  and  lessons  learned  from  the  evolution  of  the  ARPANET  to 
Internet,  the  SEANET  project  should  be  able  to  effectively  implements  its 
solutions,  meet  its  user's  requirements,  and  extend  the  life  cycle  of  the  project. 
This  will  provide  a  baseline  from  which  to  compare  the  SEANET  project 
development  proposal. 

This  chapter  will  describe  the  strategies  used  to  evolve  from  ARPANET  to 
Internet.  This  chapter  will  review  how  the  Internet  progressed.  Finally,  this 
chapter  will  list  lessons  learned  that  may  prove  useful  to  the  SEANET  project. 

B.  STRATEGIC  APPROACHES  OF  THE  EXPANSION 

1.  Introduction 

This  section  will  describe  the  strategic  approaches  used  to  evolve  from 
ARPANET  to  Internet.  Research  into  the  evolution  of  the  Internet  provides  three 
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(3)  strategic  approaches  that  resulted  in  the  evolution  of  the  Internet.  These 
approaches  involve  the  descriptions  of  the  spirit,  the  standards,  and  the  organiza¬ 
tion  and  management  style  that  represent  how  the  Internet  evolved. 

2.  The  Spirit  of  the  Internet  Evolution 

The  spirit  of  the  evolution  was  one  of  pure  research  initially  (Hauben, 
1995).  The  researchers  had  an  abstract  task  to  develop  a  manner  to  conduct 
command  and  control  in  the  event  of  a  nuclear  attack.  The  researchers  felt  the  best 
way  to  achieve  this  task  was  with  a  collaborative  spirit.  They  sought  open 
participation  of  any  group,  person,  or  idea  that  would  benefit  this  community  of 
researchers  having  the  common  interest  of  connecting  computers  together.  The 
researchers  were  not  interested  in  only  developing  a  military  product.  This  attitude 
and  approach  seems  odd  for  a  group  that  is  ultimately  solving  a  purpose  for  the 
military  but  fits  with  the  time  period  of  the  projects  beginnings  —  the  mid  to  late 
1960s. 

3.  The  Standards  of  the  Internet  Evolution 

The  standards  maintained  and  demanded  of  the  researchers  by  themselves 
was  critical  to  the  evolution  of  the  Internet.  The  expectation  was  that  in  order  to 
make  this  work  at  a  grand  level  that  "the  best  academic  computer  centers"  (ARPA 
draft  III-7)  must  be  used.  The  concept  of  a  "Grand  Design"  is  one  of  a  comprehen¬ 
sive  design  that  accounts  for  almost  all  possible  foreseen  uses  of  the  technology 
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being  developed  or  the  infrastructure  being  built.  Using  the  best  academic  centers 
served  two  purposes:  (1)  to  get  the  best  people  and  resources  working  on  the 
problem,  and  (2)  ensure  development  of  interactive  computer  technology  occurred 
at  a  level  that  was  not  merely  commercially  expedient. 

4.  The  Organization  and  Management  Style  of  the  Internet 
There  must  be  an  organizational  structure  and  management  style  that  is 
focused  on  high  level  goals.  An  organization  that  promotes  the  project 
development  process  but  is  not  just  immediately  concerned  with  the  process 
yielding  an  instantaneously  profitable  solution.  ARP  A,  the  precursor  of  the 
DAPRA,  charter  tends  toward  the  research  end  of  research  and  development 
focusing  on  functions  as  opposed  to  specific  products  (Buddenberg,  1997).  This 
constitutes  a  goal  oriented  process  versus  a  product  oriented  process.  The 
management  style  must  be  supportive  not  directive  yet  ensure  that  there  is  enough 
cohesion  to  integrate  and  trigger  system  planning  events  after  each  advance  and 
breakthrough.  This  style  is  appropriate  when  not  constrained  by  time  nor 
resources.  Time  nor  resources  appeared  to  have  been  a  problem  in  the  late  1960s. 

C.  PHASES  OF  THE  INTERNET  DEVELOPMENT 
1.  Introduction 

This  section  will  give  a  description  of  the  phases  of  the  evolution  of  the 
Internet  from  its  origins  as  the  in  the  ARPA.  The  Air  Force  commissioned  Paul 
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Baran  of  the  Rand  Corporation  to  study  how  to  command  and  control  strategic 
nuclear  forces  after  a  nuclear  explosion  (Tappendorf,  1995).  Baran  determined 
that  a  packet  switched  network  with  no  central  command  center  or  hub  would  best 
accomplish  this  task  (Tappendorf,  1995).  This  lead  to  network  research  in  how  to 
achieve  this  concept.  This  research  initially  was  done  under  the  auspices  of 
ARP  A.  The  ARPANET  phase  was  followed  by  the  National  Science  Foundation 
assuming  responsibility  for  the  Internet  to  achieve  greater  usage  of  the  technology 
for  purposes  other  than  military  research,  command  and  control.  The  final  phase  is 
our  present  Internet  commercial  phase.  This  section  will  describe  what  happened 
to  provide  the  basis  for  SEANET  research  and  development  in  non-terrestrial 
networks.  It  will  also  discuss  what  went  well  and  not  so  well  during  this  period. 

2.  The  ARPANET  Phase 

a.  What  Happened  in  this  Phase 

This  phase  deals  with  the  period  from  Baran's  research  in  1966  to 
1984  when  NSF  became  responsible  for  the  present  day  Internet.  This  phase  is 
marked  by  the  era  of  large  mainframe  computer  operated  by  technically  savvy 
programmers  for  the  benefit  of  the  government,  universities,  and  large  companies 
that  could  afford  to  operate  mainframe. 

(1)  Research.  In  1964  the  director  of  DARPA  testified 
before  Congress  that  the  next  steps  in  computing  would  be  to  link  individuals 
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through  computers.  (Norberg,  1955)  This  led  to  the  push  to  link  computers  via  a 
network  under  the  auspices  of  DARPA's  Information  Processing  Techniques 
Office  (IPTO).  This  resulted  in  Requests  for  Proposals  (RFP)  in  networking  from 
DARPA  in  July  1968  (Kulikowski,  1994).  Professors  and  students  at  UCLA 
"proposed  to  DARPA  to  organize  and  run  a  Network  Measurement  Center  for  the 
ARPANET  project"  (Cerf,  1993).  Research  continued  at  UCLA  in  the  area  of 
observing  behavior  of  a  networks  until  September  1969.  2  September  1969  was 
when  four  Interface  Message  Processors  (IMP-1)  computers  at  UCLA,  SRI, 
UCSB,  and  University  of  Utah  were  linked  by  a  circuit  to  allow  for  actual  study  of 
network  behavior. 

(2)  Engineering.  The  immediate  operation  of  this  four 
node  network  proved  that  the  packet-switched  concept  of  Paul  Baran  would  work. 
The  next  step  was  to  get  that  concept  to  work  on  many  dissimilar  types  of 
computers.  Steve  Crocker,  a  graduate  student  at  UCLA,  led  the  design  of  protocols 
for  host  computers  to  operate  on  the  APRANET  (Tappendorf,  1995). 

(3)  Infrastructure.  Progress  in  developing  and  expanding 
the  ARPANET  infrastructure  occurred  slowly.  There  were  many  different 
platforms  that  needed  the  hardware  and  software  that  would  use  protocols  to 
connect  the  different  architectures  to  the  ARPANET  (Cerf,  1993).  This  protocol 
was  the  Network  Control  Protocol  (NCP)  in  1971.  There  was  still  little  incentive 
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to  develop  the  infrastructure  quickly.  This  incentive  appeared  in  the  form  of  an 
opportunity  to  demonstrate  how  the  ARPANET  worked  at  the  International 
Conference  on  Computing  Communication  in  1972.  The  demonstration  showed 
how  ARPANET  could  run  applications  all  over  the  U.S.  The  success  of  the 
demonstration  led  to  the  establishment  of  the  International  Network  Working 
Group  (INWG)  organized  and  chaired  by  Vinton  Cerf  (Cerf,  1993)  to  further 
develop  the  infrastructure.  It  began  to  look  for  other  ways  to  transmit  data.  It 
launched  two  projects:  (1)  satellite  transmission  of  data  that  became  an 
operational  network  named  SATNET  in  1976  and  (2)  a  packet  switched  radio 
network  (Tappendorf,  1995).  These  two  projects  made  NCP  unable  to  meet  the 
networks  needs.  Cerf  got  placed  in  charge  of  the  whole  Internet  after  being  hired 
by  IPTO  to  further  develop  the  Internet  and  design  protocols  for  packet  radio, 
satellite,  and  terrestrial  Internet.  In  1973,  Cerfs  group  developed  Transmission 
Control  Protocol/Intemet  Protocol  (TCP/IP).  Internet  Protocols  become  opera¬ 
tional  in  1978  (Cerf,  1993).  DOD  began  experimenting  with  its  use  and  later 
required  it  for  ARPANET.  The  protocols,  that  would  later  result  in  the  network 
later  being  called  the  Internet,  were  bom  1  January'  1983  when  NCP  was 
deactivated  and  TCP/IP  became  the  protocol  on  APRANET.  In  1984,  USD(R&E) 
chose  ARPANET  technology  over  Autodin  II  for  the  Defense  Data  Network. 
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(4)  Applications.  A  critical  portion  of  this  section  are  the 
applications  that  breathed  life  into  the  technology.  The  services  that  proved 
essential  prior  to  the  ARPANET  demonstration  in  September  1972  include  the  first 
email  program  by  Larry  Roberts  in  1969,  dial-up  services  for  remote  terminals 
developed  called  TELNET  in  1972,  and  file  transfer  protocols  (FTP).  Other 
developments  that  enhanced  the  Internet's  developments  include  BITNET  in  1981, 
a  store  and  forward  network;  CSNET  in  1981,  a  peer  exchange  mail  service;  and  in 
1983  the  development  of  the  Domain  Name  Server  (DNS)  that  allowed  message  to 
ask  for  directions  to  its  destination  thus  easing  administration  of  machines  and  use 
by  participants  of  the  network.  DNS  pairs  names  with  numbered  IP  addresses  to 
assist  in  routing. 

(5)  Scaling  Issues.  The  original  design  of  the  network 
address  space  only  considered  the  need  for  256  networks.  Based  on  those  times, 
this  seemed  more  than  adequate.  To  handle  many  local  area  networks  and  the 
limitations  of  the  address  space,  INWG  developed  the  concept  of  Class  A,  B,  and 
C  networks  as  a  means  of  partitioning  the  32-bit  address  space  (Cerf,  1993). 
Today  the  address  space  is  becoming  overwhelmed  but  IPv6,  the  next  generation 
IP  should  solve  the  explosive  need  for  network  Ids. 


11 


b.  What  Went  Well  and  Not  Well  In  This  Phase 
There  are  three  things  that  went  well  during  this  phase.  They  were 
the  pursuit  of  basic  research,  the  establishment  of  a  grass  roots  community  in  the 
field  of  network  computing,  and  the  consolidation  of  the  techniques  to  move  from 
a  mainframe  world  of  computing  to  a  distributed  form  of  computing.  Basic 
research  spawned  the  development  and  experimentation  with  different  ways  to 
communicate.  The  relationships  developed  among  the  early  pioneers  of  networks 
computing  has  altered  the  world  through  the  systems  they  developed,  the 
companies  they  formed,  and  the  community  they  fostered.  This  is  also  a  period  of 
consolidation  of  techniques  to  handle  the  ability  for  computers  to  communicate  or 
transmit  data  from  a  large  set  of  architectures,  hardware  and  software  techniques  to 
a  protocol  that  is  still  in  use  today:  TCP/IP.  The  two  big  payoffs  were:  (1)  TCP 
and  IP,  as  state  and  stateless  machines  respectively,  laid  the  foundation  for  scaling 
and  (2)  TCP/IP  (in  the  large)  is  operating  system  agnostic  since  these  protocols 
have  been  implemented  on  dozens  of  operating  systems.  The  one  thing  that  did 
not  go  well  during  this  period  was  implementation  of  scaling.  The  original 
pioneers  did  not  comprehend  that  there  would  ever  be  a  need  for  more  than  256 
networks  back  in  1973  since  there  were  so  few  networks  and  since  no  one  could 
fathom  the  impact  that  networking  would  have  on  the  world.  However,  it  is 
important  for  any  future  development  in  that  the  designer  must  think  not  only 
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about  how  to  meet  the  requirement  but  also  how  the  design  might  be  used  for 
purposes  not  intended  or  stated  in  the  original  requirement.  The  domain  name 
server  concept  was  key  to  mitigating  this  scaling  problem  that  is  a  opportunity  for 
network  designer  of  the  future. 

DNS  went  through  at  least  a  couple  of  stages  of  evolution  significant 
to  the  scaling  issue.  The  first  approach  was  to  have  a  host  file  in  each  end  system. 
The  IP-name  pairing  is  a  list  in  a  file  on  each  end  system  kept  its  own  list.  Every 
time  a  new  host  was  added  every  end  system  updated  their  host  files.  The  second 
approach  was  the  use  of  a  centralized  host  file  at  the  NIC.  New  host  were  added  to 
the  NIC's  host  file.  Periodically,  the  host  file  was  FTPed  to  end  systems. 
Centralization  caused  the  updates  to  always  be  behind  and  the  overhead  that 
resulted,  although  better  than  manual  updates,  was  rapidly  overtaken  by  network 
growth.  The  third  stage  was  the  invention  of  DNS  done  by  Paul  Mockapetris  that 
is  a  classical  decentralized  database  (Buddenberg,  1997). 

3.  The  ARPANET  to  NSFNET  Phase 

The  next  phase  is  considered  the  transition  from  the  ARPANET  to  the 
NSFNET  phase.  The  NSFNET  phase  can  be  considered  a  time  for  expanded 
usage.  Rather  than  just  use  the  network  for  command  and  control  usage, 
researchers  of  any  variety  would  purchase  time  to  use  the  super  computer  centers. 
This  move  added  credibility  to  the  net  since  the  entire  research  community  began 
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using  the  network.  It  was  not  just  the  Defense  Department  nor  just  the  computer 
science  community  that  saw  the  advantages  of  having  a  new  way  to  communicate. 
Upgrades  to  the  backbone  occurred  to  meet  the  growing  needs  of  the  overall 
community.  Higher  speed  networking  and  easier  access  led  to  more  users.  These 
users  were  now  able  to  do  more  things  because  of  the  ability  to  transfer  greater 
amounts  of  data.  This  section  will  describe  how  the  research,  engineering, 
infrastructure,  and  general  activities  developed  during  the  period  of  1984  to  1995. 
a.  What  Happened  In  This  Phase 

(1)  Research.  This  period  represents  stability  and  broad 
based  growth  of  the  Internet  within  the  research  community.  NSF  decided  to 
become  involved  in  networking  with  the  establishment  of  five  super  computer 
research  centers  connected  to  each  other  by  a  backbone  that  was  linked  to  the 
ARPANET  (Tappendorf,  1995).  Researchers  could  purchase  time  on  this  network. 
This  NSFNET  became  very  popular  and  resulted  in  network  traffic  exceeding  the 
capability  of  the  NSF  backbone  and  ARPANET.  The  backbone  needed  upgrades 
that  NSF  itself  was  not  interested  in  managing.  In  1985,  NSF  deployed  its 
upgraded  backbone  to  a  T1  connection  that  Merit  Corp.,  MCI,  IBM,  and  U.  of 
Michigan  (U  of  M)  developed  (Kulikowski,  1994).  By  October  1985  most 
ARPANET  users  were  shunted  to  the  NSFNETs  T1  connection  with  the 
ARPANET'S  56Kbps  connection  being  decommissioned  in  1990.  Merit,  IBM, 
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MCI,  and  U  of  M  later  formed  a  non-profit  firm  called  Advanced  Network 
Systems  (ANS)  that  did  high  speed  networking  research.  In  1987,  Computer 
Engineering  Research  Network  (CERN)  was  created  from  the  merger  of  BITNET 
and  CSNET.  There  research  later  developed  the  World  Wide  Web  technology  that 
transformed  the  Internet. 

(2)  Engineering.  During  the  period  that  the  NSF 
influenced  the  Internet's  development  there  really  were  not  many  changes  to  the 
physical  network.  NSF,  however,  did  encourage  the  wide  spread  use  of  the  Internet 
in  the  non-commercial,  academic,  and  government  research  communities.  The 
credibility  and  funding  that  NSF  provided  to  the  Internet  fostered  growth  beyond 
expectations.  Every  time  the  NSF  increased  the  size  of  the  backbone,  traffic  on  the 
network  increased  to  fill  the  capacity. 

(3)  Infrastructure.  NSF's  involvement  was  critical  to  the 
improvements  in  infrastructure.  This  proved  expensive.  At  first,  NSF  sought  to 
connect  researchers  directly  to  one  of  the  five  super  computer  centers.  The 
demand  for  service  made  the  cost  of  running  these  connections  prohibitive. 
Therefore,  NSF  began  to  fund  connections  to  research  centers  already  connected 
the  NSFNET  rather  than  directly  to  one  of  the  five  super  computers.  The  final 
improvement  in  infrastructure  to  NSFNET  occurred  in  1991  when  NSF  connected 
all  sites  via  a  T3  connection  developed  from  the  research  of  ANS.  The  network 
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continued  to  grow  immensely.  Accordingly  in  1991,  NSF  created  a  new  network 
called  the  National  Research  and  Education  Network  (NREN)  to  be  a  non¬ 
commercial  network  for  high  speed  networking  research.  The  network  was 
becoming  unmanageable  from  NSF's  view. 

(4)  Applications.  The  key  application  developed  during 
this  phase  is  the  WWW  technology.  The  technology  provided  the  ability  to 
connect  documents  to  other  forms  of  media  in  the  form  of  a  global  information 
database.  It  provided  a  way  for  Internet  users  to  use  graphics  and  hypertext.  This 
allowed  non-technical  users  to  visualize  and  search  for  information  in  a  very 
intuitive  ways.  This  further  increased  usage  of  the  Internet  and  forced  NSF  to 
reconsider  its  role  in  the  Internet. 

(5)  Scaling  Issues.  NSF  realized  their  network  was 
operating  differently.  Therefore,  they  announced  they  would  no  longer  allow 
direct  access  to  the  backbone.  Instead  access  would  be  purchased  from  a 
contractor  representing  NSF.  NSF  gives  the  following  reasons  for  this:  (1)  the 
government  does  not  want  to  be  in  the  communications  business  and  (2)  this 
allows  for  commercialization  of  the  net  as  the  government  restricts  commercial 
use.  The  result  is  the  commercial  Internet  is  bom. 
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b. 


What  Went  Well  and  Not  Well  In  This  Phase 


NSF  realized  the  net  was  working  differently  and  not  along  the 
established  purposes  of  this  governmental  foundation.  This  revelation  marks  the 
end  of  this  phase  and  the  beginning  of  the  transition  to  the  commercial  Internet. 
1988  to  1993  was  a  period  of  major  growth  from  the  order  of  magnitude  of 
thousands  of  users  to  millions  of  users  (Rutkowski,  1997).  The  research  and 
commercial  aspects  of  the  network  began  leaping  ahead  of  the  military  sector  with 
NSF  upgrading  to  T1  and  T3  connections  while  DOD  was  still  using  56kbps 
connections  (Buddenberg,  1997). 

4.  The  Internet  Phase 

The  Internet  Phase  began  with  the  NSF  contracting  with  access  providers  in 
order  to  get  government  out  of  the  communications  business  and  to  allow 
commercialization  of  the  net.  This  last  phases  of  placing  the  Internet  in  the 
commercial  sector  provides  the  basis  for  the  free-wheeling  nature  of  the  Internet 
today.  It  directly  placed  the  marketing  of  products  and  services  based  on  market 
forces  that  exploit  Internet  technology  in  the  private  sector  after  the  infrastructure 
of  building  the  Internet  had  been  established. 

a.  What  Happened  In  This  Phase 

(1)  Research.  This  phase  is  still  evolving.  The  research 
that  occurs  is  in  the  areas  of  high  speed  networking,  modifying  the  address  space 
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to  deal  with  the  ever  increasing  market  demand  for  network  identification  address 
and  user  identification  address,  and  how  to  standardize  and  consolidate  the  best 
platforms,  protocols  and  channels  for  efficient  use  of  Internet  resources.  The 
concept  of  ubiquitous  computing  is  for  people  to  communicate,  collaborate,  work 
and  play  no  matter  what  platform  they  use  nor  whether  they  are  on  land,  at  sea,  or 
in  space  above  the  earth.  The  SEANET  project  is  an  example  of  the  type  of 
research  being  conducted  to  achieve  the  integration  and  expansion  of  Internet 
access  across  the  globe. 

(2)  Engineering.  Before  solutions  to  evolve  the  Internet 
into  a  ubiquitous  communications  medium  can  occur,  consensus  must  develop 
between  the  ever  increasing  number  of  community  of  users  or  stakeholders  with  an 
interest  in  the  Internet.  The  Internet  is  not  just  a  network  for  the  use  of  the 
technologically  savvy.  The  many  stakeholders  include  governmental  bodies  across 
the  globe,  international  and  multi-national  corporations  including  broadcast  tele¬ 
vision,  telecommunications,  and  satellite  providers,  the  academic  and  research 
communities,  and  private  citizens  from  every  walk  of  life.  These  varied  stake¬ 
holder's  desires  all  must  be  negotiated  prior  to  designing,  building  and 
implementing  any  adjustments  or  major  enhancements  to  the  Internet.  Therefore, 
solutions  are  falling  into  the  realm  of  the  world  political  structure  because  all 
stakeholders  realize  that  far  too  much  money  and  far  too  much  power  can  be 


shifted  by  the  use  and  abuse  of  the  Internet.  Consensus  must  be  achieved  before  a 
solution  arrives.  This  impacts  the  infrastructure. 

(3)  Infrastructure.  The  infrastructure  that  supports  the 
Internet  is  undergoing  consolidation  and  integration  in  order  to  take  advantage  of 
economies  of  scale.  Basic  economics  and  market  forces  are  causing  different 
stakeholders  to  follow  different  strategies  to  compete  in  providing  what  customers 
want  and  meeting  demand.  Examples  of  this  include  the  merger  of  MCI  (one  of 
the  first  providers  of  Internet  access)  and  British  Telecommunications  (BT).  In 
1993,  when  the  NSF  subsidies  ended,  all  the  non-profit  ISPs  either  reinvented 
themselves  as  for-profit,  taxpaying  entities  or  they  got  bought  up  by  for-profit 
corporations.  None  of  the  formerly  non-profit  ISPs  folded.  The  significance  is 
that  the  non-commercial  acceptable  use  policy  went  away  and  the  five-year  NSF 
subsidy  period  turned  a  neat  military  R&D  program  into  an  industry.  Partnerships 
are  developing  to  generate  the  skills  and  capital  to  invest  in  the  large  dollar  game 
of  evolving  the  Internet  to  the  world's  needs  not  just  any  one  isolated  group  of 
individuals  needs.  This  business  process  of  adjusting  the  structure  to  meet  the 
visualized  end  state  is  occurring  right  now.  How  this  plays  out  is  yet  to  be 
determined.  Market  forces  have  proven  the  most  efficient  way  to  achieve  the 
highest  quality  products  and  services  at  the  most  economical  prices  as  long  as 
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there  is  competition.  This  author  believes  that  this  will  continue  to  be  the  case. 
This  might  alter  the  products  and  services  currently  available. 

(4)  Applications.  The  following  is  a  list  of  the  major 
applications  and  services  that  are  being  provided  on  the  Internet.  These 

applications  and  services  become  possible  mainly  due  to  higher  capacity,  varied 
classes  of  service,  enhanced  protocols,  added  complexity,  transition  to  multimedia 
technologies,  and  transition  to  truly  mobile  clients  and  servers.  The  present  and 
emerging  generic  applications  fall  into  these  major  categories  (Catlett,  1993): 

1 .  Text  file  transfer  (FTP) 

2.  Electronic  mail  (SMTP) 

3.  Remote  login  (TELNET) 

4.  Video  teleconferencing 

5.  Interactive  visualization 

6.  Composite  imaging 

7.  Multimedia  mail 

8.  Character  data  transfer 

9.  Multimedia  database  access 

10.  Collaboration  technology 

1 1 .  Image  transfer 

12.  Distributed  computing 
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Services  that  continue  to  evolve  and  emerge  include  providing  security, 
providing  directory  services,  and  providing  network  management.  Security 
services  include  confidentiality,  authentication,  integrity,  access  control,  and  non¬ 
repudiation  (Kent,  1993).  Directory  services  provide  for  users  to  locate  and 
identify  network  objects.  These  directory  services  include  a  way  for  users  to  find 
other  users  on  a  local  host  called  FINGER,  a  way  to  allow  for  querying  a  single 
database  on  a  specified  machine  called  WHOIS,  a  method  of  dividing  Internet 
domain  networks  into  distributed  sections  to  ease  location  of  any  section  quickly 
and  reliably  called  DNS,  a  two-step  process  to  locate  users  by  searching  databases 
called  NETFIND,  X.500  (a  single,  unified,  worldwide  system  that  completely 
describes  all  OSI  resources),  and  WAIS  (to  target  coordinated  access  to 
information).  The  final  service  category  is  that  of  network  service.  The  primary 
network  service  in  the  Simple  Network  Management  Protocol  (SNMP).  SNMP 
provides  for  remote  management  of  network  resources  from  anywhere  on  the 
network. 

b.  What  Went  Right  In  This  Phase 

What  went  right  in  this  phase  is  a  question  is  still  up  for  debate  as  the 
wide  spread  commercial  use  of  the  Internet  is  so  immature.  It  is  clear  that  the 
Internet  was  ready  to  go  commercial.  NSF  did  a  service  by  contracting  out  the 
management  and  access  of  the  Internet  to  allow  for  commercial  use.  Internet 
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Service  Providers  (ISP),  by  accepting  NSF  money,  had  to  work  under  the  NSF's 
acceptable  use  policy  that  excluded  commercial  use.  This  problem  disappeared 
when  the  NSF  money  and  acceptable  use  policy  disappeared.  This  commercial¬ 
ization  has  spawned  new  business,  careers,  lifestyles,  and  way  to  collaborate.  It 
has  also  raised  questions  of  free  speech,  security,  and  the  appropriate  use  of 
technology.  The  impact  thus  far  affects  every  human  endeavor.  This  should 
continue  but  it  too  early  to  provide  a  qualitative  assessment. 

D.  LESSONS  LEARNED 

1.  Open  System  Approach 

Various  sources  reflecting  on  the  history  of  the  Internet  discuss  the  value  of 
using  an  open  systems  approach.  In  this  context,  these  sources  do  not  merely 
discuss  the  limited  idea  of  "open  systems"  as  a  hardware  and  software  inter¬ 
operability  issue.  Rather,  the  concept  is  one  of  a  total  system  approach  using 
products,  processes  and  people  that  are  open  to  innovative  ideas,  methods  and 
products.  This  concept  is  more  rightly  viewed  as  "open  participation"  in  the 
process.  This  far  more  encompassing  concept  of  an  "open  system"  is  much  more 
an  attitude  than  a  product,  process  or  protocol. 

This  approach  manifested  itself  by  the  true  democratic  way  the  people  with 
a  common  goal  were  free  to  suggest  ideas  and  implement  solutions.  These 
solutions  were  briefed  to  the  community  and  essentially  were  voted  on.  The 


voting  took  the  form  of  computer  code  being  run  to  demonstrate  the  real  world 
implementation  of  the  idea  (Buddenberg,  1997).  This  democracy  resulted  from  an 
established  method  of  capturing  ideas  and  disseminating  through  the  establishment 
of  the  RFCs.  RFCs  were  not  only  an  historical  record  but  more  importantly  were  a 
mechanism  to  quickly  get  ideas  and  solutions  out  in  the  open  for  discussion  and 
critical  review.  This  proved  essential  to  the  development  of  the  Internet  and 
reinforced  the  relationships  and  trust  among  members  of  the  community. 

2.  Fielding  Plan  of  Host  Computers 

An  important  decision  during  implementation  was  the  sequencing  of  which 
nodes  to  bring  up  first  on  the  network.  The  first  node  was  the  host  at  UCLA.  This 
served  as  the  Network  Measurement  Center  to  capture  congestion  data  (Hauben, 
1995).  Statistics  would  be  run  on  this  data  to  assist  in  bringing  up  future  hosts  and 
in  Network  Management  and  Control.  The  other  three  original  hosts  each  had 
specific  purposes  as  well.  The  Stanford  Research  Institute  (SRI)  host  served  as  the 
Network  Information  Center  (NIC),  the  world's  first  anonymous  FTP  server.  The 
University  of  California  Santa  Barbara  (UCSB)  host  provided  interactive  mathe¬ 
matics.  The  University  of  Utah  provided  graphics  (Cerf,  1993). 

3.  Grand  Design  Versus  Operational  Network 

A  third  lesson  learned  was  the  impact  of  the  decision  over  the  initial  design 
of  the  network.  The  network  designers  "struggled  between  a  grand  design  and 
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getting  something  quickly"  (Crocker,  1993c).  The  initial  design  has  impact  not 
only  on  how  quickly  the  product  is  developed  but  also  on  what  adjustments  or 
upgrades  can  or  should  be  made  later  as  the  network  evolved.  Although  these 
pioneers  tried  to  think  as  broadly  as  possible  they  ultimately  settled  for  a  working 
network.  This  led  to  the  problem  of  scaling  that  the  Internet  is  facing  today.  "The 
somewhat  embarrassing  thing  is  that  the  network  address  is  under  pressure  now." 
(Cerf,  1993)  Had  the  initial  pioneers  thought  more  grandly  or  at  least  developed  a 
plan  to  scale  the  Internet  from  the  beginning,  the  expanding  scale  of  the  Internet 
would  not  need  to  be  addressed  today. 

The  lesson  is  to  contemplate  all  potential  users  of  your  technology  and 
protocols.  Plan  for  the  use  of  your  technology  and  protocols  by  the  intended  users 
of  your  network  but  also  develop  a  plan  to  scale  your  network  up  and  out  for 
purposes  not  initially  intended.  This  suggest  to  design  a  network  that  can  be 
scaled  at  a  later  time  rather  than  to  build  a  network  that  has  excessive  capacity 
today.  This  also  serves  the  purpose  of  generating  broader  based  acceptance  and 
support  of  the  technology  being  designed.  This  prepares  for  when/if  the 
technology  is  used  for  commercial  purposes,  that  the  project  this  technology  is 
initially  intended  for  may  benefit  by  lower  unit  costs.  Risk  needs  to  be  analyzed 
not  only  for  project  failure  but  also  for  successes  beyond  ever  imagined.  The 
answer  to  the  question  "what  if  everyone  in  the  world  has  a  computer  and  all  are 
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connected  to  the  Internet  at  the  same  time?,"  would  have  provided  some  insight 
into  the  scaling  question. 

4.  Request  For  Comment  (RFC) 

The  fourth  lesson  learned  is  to  capture  a  record  of  all  meetings  and  critical 
reviews  of  the  project.  Although  this  is  a  basic  concept,  it  should  not  be 
overlooked  as  it  serves  multiple  purposes. 

1.  It  provides  a  basis  for  people  in  the  community  that  did  not 
participate  in  meetings  or  project  review  sessions  to  understand  what 
has  transpired  and  in  what  order  decisions  have  been  made. 

2.  Documentation  is  typically  a  weakness  of  any  project. 

3.  It  captures  history. 

4.  If  there  is  any  question,  at  a  later  date,  over  intellectual  property 
rights  and  rights  of  authorship,  RFCs  provide  a  way  to  clarify  those 
issues. 

Ideally,  meetings  should  be  recorded  by  videotape  to  capture  not  only 
words  but  body  language  and  mannerisms.  Written  minutes  are  essential  to 
capture  exactly  what  is  discussed.  The  Network  Information  Center  and  the  RFC 
is  an  ideal  vehicle  to  support  this  purpose.  RFCs  were  posted  on-line  at  SRI  that 
ran  the  NIC.  RFCs  were  stored  in  the  world's  first  anonymous  FTP  server.  This  is 
in  contrast  to  other  standards  organizations  where  standards  were  copy-righted 
material  that  are  sold  for  prices  to  be  able  to  sustain  the  operations  of  the  standards 
organization. 
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5.  Management  Controls  and  Guidance 

Key  to  development  of  the  Internet  was  the  management  controls  and 
credibility  lent  to  the  network  developers.  ARPA  and  NSF  provided  critical 
guidance  at  critical  moments  in  the  history  of  the  development  that  brought  about 
success.  However,  project  control  was  not  designed  into  the  development  from  the 
start.  Instead  "Smart  management  sense  [that]  paved  the  way"  for  the  scientists  to 
create  the  ARPANET.  This  management  sense  was  provided  in  the  way  of  people 
providing  comments  and  influencing  the  community  throughout  the  project.  This 
author  interprets  this  to  mean  that  there  was  little  consideration  for  building  in  life- 
cycle  management  from  the  start  in  a  self-governing  manner.  The  researchers  had 
the  benefit  of  being  associated  with  organizations  that  had  the  breadth,  skill  and 
pragmatism  to  interject  control  at  just  the  right  time.  This  proved  very  beneficial 
and  should  be  built  into  the  design  of  any  future  network  projects. 

6.  Transition  Plan 

The  final  lesson  learned  is  that  the  ARPANET  to  Internet  project  did  not 
have  a  cohesive  acquisition  life-cycle  project  plan.  The  project  evolved  with  the 
right  people  providing  fortuitous  guidance  at  just  the  right  time.  This  loose  type  of 
project  management  process  although  flexible,  did  not  lend  itself  to  meeting  any 
meaningful  cost,  schedule,  or  performance  parameters.  However,  due  to  the  scope 
of  the  participants,  the  varied  technology,  and  the  complexity  involved  in  the 
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Internet  project  at  this  point  in  1988  when  NSF  took  over,  maybe  the  best  that 
could  have  been  expected  of  NSF  was  to  provide  the  coherence  to  all  project 
participants  so  development  could  flourish  at  the  expense  of  what  looks  to  be  a 
poorly  controlled  project  (Buddenberg,  1997). 
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III.  OVERVIEW  OF  THE  SEANET  PROPOSAL 


A.  SEANET  PROJECT  BACKGROUND 
1.  Purpose 

The  purpose  of  this  project  is  "to  provide  transparent  connectivity  for  ships 
in  the  oceanographic  research  fleet  routinely."  The  oceanographic  research  fleet 
personnel  use  the  Internet  and  WWW  on  land  for  their  research  and  they  want  to 
be  able  to  use  it  when  underway  at  sea.  They  can  communicate  while  underway 
but  each  vessel  cannot  share  data  very  well  with  the  other  research  vessels  or  with 
land-based  sites  due  to  system  incompatibilities. 

Currently  deployed  data  communications  limit  the  task  of  best 
supporting  oceanographic  research  today.  Although  data  commun¬ 
ication  to  and  from  ships  is  common,  each  ship  has  its  own  way  to 
send  email,  transfer  files,  or  perhaps  provide  interactive  services. 

The  communications  cost  for  these  services  are  high  and  users  often 
experience  low  throughput  and  a  variety  of  communications  systems 
problems.  (Kappel,  1997) 

Technical  support  at  sea  is  spread  thin.  Typically,  each  remote  unit  will 
have  one  technician  that  has  to  keep  all  the  oceanographic  equipment  operational 
along  with  being  the  network  manager.  Remote  network  management  is  not  in  the 
system  at  this  time  (Buddenberg,  1997). 
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2.  Project  Participants  and  Roles 

a.  Introduction 

This  section  describes  those  organizations  that  are  involved  in  the 
SEANET  project  and  the  roles  that  each  organization  plays.  The  participants  are 
organized  into  two  levels  of  participation:  primary  and  supporting.  The  primary 
participants  generally  have  a  specific  role  or  function,  are  required  to  provide  a 
deliverable  product,  and  they  have  an  interest  in  the  Oceanographic  Fleet.  The 
supporting  participants  provide  limited  products  and  services  and  generally  do  not 
have  an  interest  in  the  Oceanographic  Fleet  other  than  through  providing  computer 
communications  to  the  fleet. 

b.  Primary  Participants 

This  material  is  a  recap  of  the  Seanet  proposal  submitted  to  the 
Office  of  Naval  Research  (ONR)  in  1997  to  develop  a  capability  for  the 
oceanographic  research  fleet. 

Joint  Oceanographic  Institute  (JOI)  provides  liaison  and  are  a 
primary  SEANET  project  coordinator.  They  interact  with  federal  agencies  and  the 
science  community.  The  also  coordinate  with  the  Advisory  Panel. 

Woods  Hole  Oceanographic  Institute  (WHOI)  shares  duties  as  a 
primary  SEANET  project  coordinator  and  is  the  responsible  agent  for  the 
Shipboard  Communications  Node  (SCN)  development. 


Lamont-Doherty  Earth  Observatory  (LDEO)  is  the  responsible  agent 
for  INMARSAT-B  procurement.  They  are  also  responsible  for  shipboard  system 
installation  and  testing. 

OMNET,  Inc.  is  the  responsible  agent  for  the  SEANET  Operations 
Center.  They  are  also  responsible  for  billing  and  use  accounting  of  the  SEANET 
network.  They  also  provide  value  added  services  as  necessary. 

Naval  Postgraduate  School  (NPS)  is  the  responsible  agent  for  the 
Shipboard  Implementation  Laboratory.  They  monitor  emerging  technology.  They 
also  act  as  the  liaison  agent  with  the  US  Naval  Research  and  Development  Center 
(NRaD). 

Individuals  from  these  organizations  recognized  an  internet 
extension  would  be  a  significant  enhancement  to  the  oceanographic  research  fleet 
mission  but  budgetary  sponsors  did  not  until  1997.  Sponsorship  in  the  form  of 
money  and  commitment  occurred  in  1996  that  funded  research  and  development  in 
1996.  (Buddenberg,  1997) 

c.  Supporting  Participants 

The  following  groups  and  organizations  provide  services  and 
products  that  the  SEANET  primary  participants  are  leveraging  to  achieve  their 
project  goals.  These  supporting  participants  are  as  follows: 
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COMSAT  is  a  satellite  communications  vendor.  They  will  provide 
reduced  rates  for  access  to  their  satellite  communications  channels.  They  provide 
engineering  support  and  potentially  enhanced  services  as  satellite  technology 
improves. 

MAGNAPhone  provides  20%  hardware  discounts.  They  will  assist 
with  engineering  support  and  they  benefit  by  having  key  input  into  their  product 
design  from  the  SEANET  prototypes. 

MCI,  Inc.  will  provide  free  circuits  and  act  as  the  SEANET  project's 
terrestrial  Internet  Service  Provider. 

The  US  Naval  Research  and  Development  Division  (NRaD)  is  a 
component  of  the  NCCOSC.  They  will  provide  technological  transfer  of  military 
unique  solutions  that  have  application  to  non-military  users  will  underway  at  sea. 

NAVOCEANO  is  an  organization  involved  in  oceanographic 
research  that  is  interested  in  lending  support  to  the  SEANET  project  for  transfer 
back  into  the  military  once  proof  of  principle  occurs.  They  are  peers  to  university 
oceanographic  research  personnel. 

3.  Project  Strategy 

Seanet  participants  want  to  replicate  what  NSF  did  with  the  regional  ISP, 
start  a  commercial  industry,  but  in  remote  regions.  They  want  to  provide  at-sea 
internet  service  the  way  terrestrial  service  is  provided  today. 
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4.  Project  Objectives 

The  SEANET  project  has  six  primary  objectives. 

a.  Provide  Communication  Channels 

The  project  is  interested  in  integrating  ships  underway  with  land 
based  stations  using  various  radio  links.  Those  presently  known  are  INMARSAT- 
B  Channel  at  64kbps,  cellular  telephone  at  9.6kbps,  AMSC  satellite  channels  at 
4kbps,  and  High  Frequency  radio  channels  at  2.4kbps. 

b.  Provide  Reasonable  Data-Communication  Rates 

The  project  aims  to  provide  incentives  for  oceanographic  research 
fleet  users  to  utilize  the  SEANET  network  for  their  research.  This  is  not  only  to 
increase  the  community  of  users  so  that  there  is  acceptance  of  the  technology  but 
also  to  generate  the  market  forces  that  will  result  in  lower  rates  unsupported  by 
subsidies.  This  is  an  issue  of  economy  of  scale.  The  oceanographic  research  fleet 
benefits  by  pooling  its  own  resources.  Furthermore,  if  a  generic  capability  is 
developed  that  is  useful  to  other  users  beside  the  research  fleet,  the  research  fleet 
can  benefit  by  buying  services  at  marginal  costs. 

c.  Provide  Network  Operation 

Essentially,  this  entails  providing  the  functions  of  an  Internet  Service 
Provider  (ISP)  dedicated  to  the  SEANET  project.  These  functions  include  point  of 
presence  for  all  wireless  channels,  firewalls  to  limit  access  into  the  SEANET  for 
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only  authorized  users,  network  management,  standard  terrestrial  ISP  services,  and 
maintaining  a  shore-base  SCN.  This  support  is  a  form  of  venture  capital  that 
assists  in  growing  an  industry. 

d.  Provide  Network  Information  Services 

These  services  include  shipboard  installation  support,  24  hour 
customer  services  for  ships  underway,  business  services  for  billing  and  accounting 
for  carrier  use,  and  web  page  development,  maintenance  and  distribution.  These 
services  are  another  form  of  venture  capital. 

e.  Integrate  Internet  Over  HF  Radio 

Tailor  technology  already  developed  by  the  US  Navy  through 
technology  transfer  to  integrate  Ship-based  and  Shore-based  stations  in  the 
SEANET  network. 

f  Establish  SEANET  Testing  and  Technology  Laboratory 

The  Naval  Postgraduate  School  provides  graduate  education  to 
members  of  the  Department  of  Defense  that  have  a  professional  interest  in  mobile 
platform  communication.  Therefore,  NPS  has  the  space,  testing  equipment,  and 
personnel  that  naturally  provide  value  to  the  project  through  testing  of  new 
techniques  and  technology.  Testing  can  involve  new  technologies  such  as  new 
communications  channels,  remote  network  management,  and  equipment  upgrades. 
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5.  Objective  Limitations 


There  are  three  key  limitations  to  achieving  these  objectives  as  the  project  is 
currently  scoped.  They  involve  infrastructure,  protocols,  and  a  business  model. 
The  following  are  infrastructure  limitations. 

1 .  AMSC  links  suffers  from  propagation  delays  that  severely  degrades 
performance  of  highly  interactive  applications.  This  link  is  func¬ 
tional  but  only  for  coverage  in  North  America  and  to  100  miles  off¬ 
shore.  It  is  only  narrow-band  voice  capable  at  this  time. 

2.  The  INMARSAT-B  link  also  suffers  from  propagation  delays  but 
offers  global  coverage  except  at  high  latitudes. 

3.  High-Frequency  (HF)  offers  global  coverage  but  atmospheric 
conditions  can  result  in  coverage  being  blocked  out  at  specific  ship 
or  shore  locations. 

4.  The  cellular  technology  requires  a  grid  of  receivers  in  close 
proximity  to  the  moving  ships.  There  is  not  a  cellular  grid  at  sea  or 
in  remote  areas  like  the  terrestrial  cellular  grid  in  built  up  areas  to 
pass  signals  to  the  ground  or  satellite  system. 

5.  All  these  links  are  all  circuit-switched  point  to  point  voice  telephone 
type  systems  versus  packet-switched  IP  type  systems.  Therefore, 
adjustments  must  be  made. 

The  protocol  limitations  assume  ethemet-like  connectivity.  Ethernet  uses 
three  way  handshakes  that  do  not  fit  the  intermittent  service  and  batch  orientation 
of  radio  links  nor  does  it  fit  into  the  telephone  system  channels.  None  of  the  links 
above  provide  a  presence  all  the  time  like  a  wireline  ethemet  system. 
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There  are  three  business  model  limitations.  The  connectivity  providers 
need  to  move  from  the  packet-switched  mentality  from  the  circuit-switched  mind¬ 
set.  A  community  of  users  must  be  nurtured  to  demand  the  capability  and  this  can 
only  done  with  incentives  to  pursue  Seanet  goals.  Commercial  ISP  must  be 
convinced  through  the  prospect  of  profits  and  technical  capability  that  the  Seanet 
goals  are  feasible. 

6.  Project  Organization 

This  project  is  organized  as  a  collaboration.  Two  of  the  primary  partici¬ 
pants  (Maffei  and  Heinmiller)  felt  the  project  would  be  "more  successful  if  there 
was  a  community  wide  consortium."  The  project  participants  have  different  skill 
and  traits  that  lend  themselves  to  an  Integrated  Product  Team  (IPT)  approach.  The 
project  group  seeks  "all  parties  interested  in  pursuing  the  goals  [of  the  project]  ...in 
a  consensus  style.  The  project  group  realizes  that  planning  is  critical  to  a 
successful  IPT  approach  but  project  coordination  is  vitally  important.  The  project 
group  assigned  responsibility  for  technical  control  to  Mr.  Maffei  and  community 
coordination  to  Dr.  Ellen  Kappel. 

B.  NETWORK  DESCRIPTION 

This  section  will  describe  the  SEANET  network.  It  consists  of  shore-based 
systems,  ship-based  systems,  and  the  communication  channels  that  provide 
connectivity  between  ship  and  shore. 
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1. 


Shore-Based  System 


This  portion  of  the  network  provides  the  interface  between  the  SEANET 
and  the  traditional  Internet.  This  is  achieved  by  a  Network  Operations  Center 
(NOC)  run  by  MCI  that  uses  a  router  and  the  SEANET  Wide  Area  Network  to 
connect  to  the  Internet.  OMNET  will  run  the  Network  Information  Center  (NIC) 
services  using  their  own  host  computers  connected  to  the  NOC.  OMNET  also  has 
the  accounting  and  billing  responsibilities  to  ensure  that  users  are  being  charged 
accurately  based  on  established  rates.  A  frame-relay  network  will  connect  to  the 
hosts  that  transfer  to  the  Up-link/Down-link  points  depending  on  the  type  of 
communications  channel  the  users  chooses  or  is  forced  to  use  to  access  the  Shore- 
based  systems.  The  following  diagram  (Figure  1)  provides  that  graphic  for  the 
functions  that  occur  on  land  and  the  points  that  transmit  to  and  from  the  ships 
underway. 

2.  Ship-Based  System 

Figure  2  shows  the  ship-based  system  include  all  the  hardware  and  software 
that  necessary  to  best  optimize  the  connections  from  the  ships  underway  through 
the  various  communications  channels  available.  Each  research  vessel  will  possibly 
have  multiple  researchers  working  different  projects  from  nodes  connected  to  the 
shipboard  Local  Area  Network  (LAN).  The  SEANET  Communication  Node 
(SCN)  will  be  the  front-end  tool  to  optimize  connections  between  the  various 
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Figure  1.  Shore-Based  System 


Figure  2.  Ship-Based  System 

nodes  on  the  ship's  LAN  with  the  various  communication  channels  available  to 
transmit  and  receive  from  shore-based  stations. 
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IV.  APPLYING  LESSONS  LEARNED  TO  SEANET 


A.  STRATEGIC  APPROACHES  APPLIED  TO  SEANET 

1.  Introduction 

This  section  analyzes  the  SEANET  approach  to  achieving  its  stated  goals  in 
terms  of  the  strategic  approach  the  Internet  used.  This  section  will  analyze  in 
terms  of  the  spirit  of  the  SEANET  expansion,  the  standards  of  the  SEANET 
expansion,  and  the  organization  and  management  style  of  SEANET. 

2.  The  Spirit  of  the  Seanet  Expansion 

The  overall  spirit  of  the  SEANET  is  very  similar  to  the  Internet  Evolution 
but  towards  different  ends.  The  Internet  initially  was  geared  toward  pure  research. 
The  SEANET  project  has  been  focused  on  providing  a  product  to  achieve  the  set 
purpose  of  supporting  Oceanographic  Research.  This  project  is  not  as  concerned 
with  research  in  communications  purely  for  research  sake.  However,  the  SEANET 
project  is  very  similar  to  the  Internet  expansion  in  how  it  approaches  the  task.  The 
SEANET  project  follows  a  collaborative  approach  making  itself  available  to 
leveraging  the  talents  and  resources  of  those  with  interest  in  supporting 
Oceanographic  research.  The  collaborative  spirit  proved  essential  to  the  Internet 
and  likewise  should  prove  to  be  a  critical  way  for  the  SEANET  project  to  be 
successful. 
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3. 


The  Standards  of  the  SEANET  Expansion 


SEANET  is  building  a  computer  communication  network  for  the  Ocean¬ 
ographic  Research  Fleet.  They  accept  participation  of  those  organizations  and 
individuals  with  interests  in  the  Oceanographic  community.  It  is  important  to  get 
the  user  involved  in  defining  requirements  so  that  the  right  product  is  built  for  the 
right  reasons.  It  is  equally  important  to  have  the  right  people  build  the  product. 
The  Internet  evolution  set  as  a  standard  to  use  "the  best  academic  computing 
centers"  to  design  and  build  the  Internet.  This  author  has  not  seen  a  similar  stated 
standard  espoused  by  the  SEANET  project.  This  is  not  to  suggest  that  the 
organization  and  personnel  participating  in  the  SEANET  project  are  not  capable  or 
competent  in  their  respective  areas  of  expertise.  This  issue  is  that  unlike  the 
Internet  evolution,  the  SEANET  project  is  not  using  the  "best  academic 
communication  centers"  to  design,  develop,  and  build  their  networks.  The 
question  is  does  the  SEANET  project  participants  have  the  past  performance  and 
reputation  that  matches  the  Internet  collaborators  in  the  area  of  computer 
communication?  The  SEANET  project  should  consider  soliciting  participation 
from  a  larger  circle  of  academic  and  commercial  research  center  conducting 
wireless  networking  research.  The  credibility  gained  and  academic  support  might 
prove  useful. 
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4. 


SEANET  Organization  and  Management  Style 


The  final  strategic  area  to  analyze  involves  the  organization  and 
management  style  of  the  SEANET  project.  The  Internet  project  like  the  SEANET 
project  uses  a  collaborative  style.  Internet  received  critical  guidance  at  critical 
points  in  time  necessary  to  evolve  the  Internet.  The  issue  is  will  SEANET  be  as 
fortunate  to  receive  the  same  "smart  management  sense"  at  critical  points  in  time 
to  have  an  equally  or  more  successful  network  development.  The  SEANET 
Advisory  Panel  should  provide  a  role  towards  providing  management  guidance  as 
the  project  progresses.  The  issue  is  why  not  develop  a  flexible  management  plan 
and  flexible  project  controls  from  the  start  that  supports  the  development.  This 
project  is  in  the  Program  Definition  and  Risk  Reduction  (PDRR.)  Phase  of  its  life- 
cycle  and  such  a  management  and  project  control  plan  integrated  into  the  system 
design  should  prove  beneficial  in  keeping  cost,  schedule,  and  performance  goals 
on  target. 

B.  LESSONS  LEARNED  OF  INTERNET  APPLIED  TO  SEANET 

1.  Open  Systems  Approach 

This  section  analyzes  the  SEANET  project's  Open  Systems  Approach.  This 
approach  proved  invaluable  to  the  Internet  development  when  coupled  with 
utilization  of  the  best  academic  computing  centers.  The  SEANET  project  proposal 
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states  and  appears  to  actively  solicit  the  participation  of  any  organization  or 
individual  with  an  interest  in  oceanographic  research.  The  critical  aspect  of  this 
project,  the  communication  system  being  produced,  provides  a  function  that  any 
group  not  just  the  oceanographic  research  fleet  could  utilize.  Therefore,  SEANET 
should  seek  the  participation  and  actively  solicit  any  organization  or  individual 
with  an  interest  and  proven  background  in  wireless  computing.  The  project 
participants  have  been  seeking  this  participation  but  it  is  the  opinion  of  this  author 
that  the  project  participants  have  not  developed  a  formal  marketing  plan  with 
someone  whose  sole  responsibility  is  to  market  the  project  and  solicit  development 
participants.  This  expansion  of  participation  could  be  manifested  by  other  long 
haul  communication  companies,  other  satellite  companies,  and  other  technologies. 
The  list  could  include  AT&T,  GTE,  Orbcomm,  Teledesic,  Globalstar,  TRWs 
Odyssey  as  well  as  other  academic  computer  communications  researchers.  This 
expansion  should  include  the  many  different  emerging  technologies  like  Low 
Earth  Orbiting  (LEO)  Satellites  during  the  design  phase.  This  would  allow  these 
technologies  to  be  easily  and  more  inexpensively  incorporated  as  a  planned 
product  improvement  when  these  technologies  mature.  Creating  modules  for 
emerging  technologies  in  the  SEANET  Communications  Node  that  are  inactive 
until  those  technologies  mature  will  provide  the  SEANET  project  greater 
flexibility  to  adapt  and  greatly  improve  throughput  at  a  later  time  while 
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minimizing  the  cost  of  redesigning  the  system  after  it  has  been  built.  Inclusion  of 
emerging  technologies  of  LEOs  during  the  design  phases  would  provide  an  easier 
transition  to  those  mediums  once  the  technologies  become  operational  in  the  out- 
years  beyond  the  funding  period  of  this  project.  Greater  participation  of 
companies  with  capabilities  already  represented  in  the  project  should  promote 
competition  that  might  translate  in  lower  rates  to  users  and  would  ensure  that  there 
are  second  sources  for  products  and  services  should  the  sole  source  be  unable  to 
deliver. 

2.  The  Plan  For  Fielding 

The  next  lesson  learned  from  the  Internet  development  involved  the  fielding 
plan  of  the  nodes  on  the  network.  The  initial  host  computers  of  ARPANET  were 
brought  up  on  the  network  in  a  specific  order  for  well-intentioned  reasons.  The 
SEANET  project  is  a  prototype  with  a  well  diagrammed  network  topology.  The 
fielding  plan  for  the  prototype  system  is  not  a  significant  issue  since  the  entire 
land-based  infrastructure  portion  of  the  system  must  be  in  place  prior  to  the  ship- 
based  infrastructure  can  connect  through  the  SEANET  to  the  Internet.  The  land- 
based  and  ship-based  portions  can  be  installed  simultaneously  but  not  connected. 
The  SCN  controls  the  integration  of  both  the  land  and  ship  based  segments  of  the 
network.  The  issue  of  the  order  of  activation  of  the  nodes  is  not  as  critical  as  its 
was  for  the  initial  host  computers  on  the  ARPANET. 
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3.  Grand  Design  vs.  Operational  Network 

This  section  analyzes  the  decision  of  building  a  network  with  a  grand 
design  or  a  network  that  is  operational.  The  SEANET  proposal  established  as  a 
goal  to  integrate  using  common  software,  hardware,  and  protocols.  Therefore,  the 
SEANET  proposal  seeks  an  operational  network.  This  foregoes  an  opportunity  to 
design,  build,  and  operate  a  network  having  greater  appeal  to  a  larger  community 
than  the  Oceanographic  Research  Fleet.  Greater  appeal  developed  from  a  network 
with  a  larger  scope  or  grander  design  would  have  the  benefit  of  attracting  more 
users  to  the  network.  If  well  managed  and  scaled,  a  larger  network  should  reduce 
the  unit  costs  to  users  and  might  provide  even  greater  research  resources  from 
organizations  presently  participating  in  the  SEANET  project. 

4.  Documentation 

This  section  analyzes  the  documentation  and  critical  external  reviews  that 
the  SEANET  project  is  subjecting  itself.  SEANET  has  proposed  establishing  an 
on-line  repository  for  project  documentation.  They  also  will  undergo  periodic 
review  from  an  advisory  panel  to  generate  constructive  feedback  involving  all 
aspects  of  their  system  development.  At  this  early  stage  of  the  project,  what 
cannot  be  answered  is  how  the  project  participants  will  incorporate  constructive 
feedback  into  design  reviews.  This  suggests  a  need  for  configuration  control 
especially  since  new  technologies  later  developed  might  result  in  product 
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improvements  subsequent  to  completion  and  fielding  of  the  network.  It  is  more 
costly  to  make  changes  to  a  product  the  later  those  changes  are  incorporated  in  the 
life-cycle  of  the  product.  SEANET  should  not  only  capture  and  incorporate 
approved  changes  quickly  but  do  as  thorough  a  job  as  possible  in  planning  the 
easiest  and  cheapest  way  to  incorporate  the  changes. 

5.  Management  Controls 

This  section  analyzes  the  management  controls.  This  is  the  area  that  is  most 
critical  to  ensuring  the  project  meets  cost,  schedule,  and  performance  goals.  The 
project  has  identified  a  project  schedule.  The  project  schedule  already  must  be 
readjusted  due  to  delays  in  funding.  However,  there  does  not  appear  to  be  any 
controls  established  to  monitor  cost  and  schedule  and  to  sample  performance. 
Monitoring  expected  cost  and  schedules  versus  actual  cost  and  schedule  would 
provide  statistical  ways  to  understand  the  implications  of  changes  in  cost  and 
schedule.  The  concept  of  Earned  Value  would  provide  the  project  a  way  to 
understand  how  changes  in  cost  and  schedule  impacts  performance.  These 
controls  established  early  would  support  the  project  participant's  ability  to 
objectively  determine  the  trade-offs  to  make  based  on  user  requirements. 

6.  Incentives 

A  technique  DARPA  used  to  speed  the  implementation  of  infrastructure 
was  to  hold  a  demonstration  of  the  capabilities  that  the  ARPANET  could  provide. 
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DARPA  set  a  date  in  advance  to  spur  those  individuals  working  on  the  ARPANET 
to  speed  development.  It  was  a  way  to  use  the  human  nature  of  the  participants 
against  themselves.  It  established  a  mark  on  the  wall  to  jump  over.  This 
expectation  to  perform  and  not  let  the  community  of  users  down  motivated  the 
participants  to  work  towards  a  goal,  finish  those  aspects  of  the  project  that  were 
not  complete  and  make  enhancements  to  benefit  the  project.  This  technique  would 
be  a  useful  tool  for  the  SEANET  participants.  A  demonstration  of  the  SEANET 
capabilities  at  a  renowned  conference  would  serve  to  not  only  provide  an  incentive 
to  spur  development  but  what  also  be  a  way  for  the  SEANET  project  to  advertise 
their  capabilities.  This  announcement  of  capabilities  could  generate  support 
behind  that  already  achieved  to  increase  the  user  base  and  could  result  in  attracting 
other  functions  and  skill  sets  the  project  participants  might  lack  to  make  the  project 
overwhelmingly  successful. 

C.  CONCLUSION 

This  chapter  analyzed  the  SEANET  project  in  terms  of  its  Strategic 
approach  and  in  terms  of  the  lessons  learned  from  the  Internet  development.  The 
SEANET  project  is  off  to  a  good  start  based  on  its  stated  objectives.  The  have 
incorporated  some  of  the  same  strategic  approaches  that  the  Internet  used  during 
development  and  have  benefited  from  its  lessons  learned  as  well.  There  are 
differences  as  well  that  the  SEANET  project  has  not  incorporated  and  would  be 
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advised  to  do  so.  The  primary  approach  that  would  be  wise  to  enhance  is  in  the 
area  of  soliciting  the  assistance  of  more  organizations  and  personnel  with  a  proven 
reputation  in  wireless  computer  communications.  The  primary  lesson  learned 
involves  developing  management  controls  early  in  the  life-cycle  to  assist  meeting 
cost,  schedule,  and  performance  measures.  The  next  two  chapters  will  provide 
insight  into  why  a  project  management  plan  would  be  useful  and  how  to  develop  a 
project  management  plan  that  establishes  management  controls  to  enhance  the 
effectiveness  of  the  SEANET  project. 

The  question  raised  is  what  should  happen  next,  how  should  it  be 
accomplished,  and  why  should  these  steps  be  taken.  The  design  reviews  by  the 
project  collaborators  that  are  occurring  in  the  early  fall  of  1997  using  IPT  approach 
is  a  natural  way  to  integrate  and  develop  the  detailed  plans  that  provide  the 
direction  to  the  project.  These  design  reviews  are  a  perfect  opportunity  to  take  an 
inventory  of  the  skills  and  functions  that  the  project  has  at  this  point  in  its 
development,  determine  deficiencies  across  all  areas  of  the  development  that 
includes  project  policy,  system  engineering,  software  management,  test  and 
evaluation,  manufacturing  and  production,  logistics,  cost  estimation,  financial  and 
contract  management,  and  develop  techniques  to  meet  these  deficiencies.  The 
project  chose  to  act  in  a  collaborative  fashion.  As  a  result,  each  project  participant 
is  responsible  for  being  involved  in  the  pain-staking  process  of  developing  the 
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inventory,  designing  solution  or  determining  the  skills  that  must  be  present  to 
overcome  skill  and  function  deficiencies.  An  experienced  project  manager  would 
help  provide  the  business  and  management  focus.  The  project  appears  to  have  the 
technical  areas  covered  but  there  appears  to  be  some  integration  and  planning 
assistance  needed.  This  is  a  critical  point  in  the  project  because  what  develops  out 
of  the  design  reviews  will  be  what  the  project  builds.  The  design  reviews  can  be  a 
catalyst  for  coordinating  and  integrating  the  project  or  it  can  be  an  opportunity  to 
participants  to  focus  on  a  narrow  scope  of  issues  that  are  important  today  but 
forego  the  opportunity  to  develop  long  and  short  range  plans  that  meet  the  projects 
ultimate  goal  of  providing  remote  access  to  users  in  a  cost  efficient  manner. 
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V.  PROJECT  MANAGEMENT  PLAN  (PMP) 


A.  INTRODUCTION 

This  project  beckons  for  an  overarching  Project  Management  Plan  (PMP). 
A  cohesive  life-cycle  management  plan  was  a  weakness  in  the  development  of  the 
Internet.  It  should  be  addressed  by  the  SEANET  project  to  improve  the 
effectiveness  of  the  project  and  speed  development.  This  plan  would  leverage  the 
lessons  learned  from  the  ARPANET  to  Internet  expansion.  It  would  tailor  life- 
cycle  management  plans  that  have  proved  effective  in  delivering  projects  that  meet 
cost,  schedule  or  performance  goals.  The  SEANET  project  recently  received 
funding  to  pursue  its  goals.  The  SEANET  project  will  begin  a  series  of  design 
reviews  to  finalize  roles,  responsibilities,  and  establish  cost,  schedule,  and 
performance  measures.  A  detailed  project  plan  would  prove  useful  to  more 
effectively  enable  the  participants  to  meet  their  goals.  This  chapter  will  discuss  the 
rational  for  establishing  such  a  plan  that  would  make  the  SEANET  project  more 
effective  and  timely.  This  chapter  will  discuss  the  purpose  for  a  PMP  and  the 
general  procedures  to  follow. 
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B.  PURPOSE 


1.  Background  of  the  PMP 

The  SEANET  PMP  provides  the  direction  and  strategy  for  the  SEANET 
program.  While  the  PMP  should  be  done  for  all  programs,  experience  shows  that 
it  is  particularly  important  for  projects  that  integrate  many  communities  that  find 
themselves  with  common  goals.  If  the  PMP  is  done  properly,  much  of  the 
information  contained  in  it  can  be  summarized  to  form  the  System  Development 
Plan  (SDP).  The  PM  is  responsible  for  completing  the  planning  activity  in  support 
of  the  program. 

2.  Purpose  of  the  PMP 

The  purpose  of  the  PMP  is  to: 

1.  Provide  the  SEANET  program  strategy  and  plans  of  action  for 
attaining  program  objectives. 

2.  Identify  responsibilities  all  staff,  partner  &  support  organizations, 
customers,  and  contractors  who  will  work  on  the  program. 

3.  Define  the  resources  required  to  execute  the  program. 

4.  Provide  a  master  schedule  of  tasks  and  program  milestones. 

3.  Project  Manager's  Responsibility 

The  PM  serves  as  the  integrating  force  throughout  the  program,  and  it  is  the 
PM's  responsibility  to  develop  and  maintain  the  PMP  with  functional  and  technical 
support.  The  PMP  should  be  consistent  with  the  program  baseline  used  to  manage 
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program  performance  requirements,  cost  and  schedule  throughout  the  program. 
The  SEANET  project  has  various  individuals  whose  roles  is  to  coordinate  specific 
aspects  of  the  project.  It  does  not  appear  due  to  the  collaborative  nature  of  the 
SEANET  project  that  any  one  person  is  acting  in  the  role  of  Project  Manager 
whose  sole  purpose  is  to  maintain  an  overarching  management  perspective  in 
meeting  cost,  schedule  or  performance  objectives.  This  authors  suggests  that  the 
project  members  should  establish  this  role  and  develop  a  project  management  plan 
(PMP).  The  following  is  a  recommended  PMP.  The  SEANET  PMP  should 
accomplish  the  following: 

1 .  Organize  and  staff  the  program. 

2.  Support  effective  communication  of  program  information. 

3.  Establish  budgetary  and  time  estimates  for  overall  program  and 
major  work  elements. 

4.  Establish  a  common  core  set  of  management  metrics  from  which  to 
evaluate  and  control  software  development. 

5.  Manage  performance,  cost,  and  schedule  risks. 

6.  Provide  a  quantitative  framework  from  which  progress  can  be 
assessed,  variances  can  be  calculated  and  analyzed,  and  alternative 
courses  of  preventive  or  corrective  action  can  be  evaluated. 
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C.  PROCEDURES 


The  PMP  should  be  designed  to  facilitate  program  coordination, 
communication,  planning,  and  control  rather  than  provide  technical  direction  to 
participants.  Therefore,  it  should  only  developed  to  the  level  of  detail  necessary  to 
apportion  the  work  among  the  functional  activities  within  the  SEANET 
community  and  other  parties  involved  in  the  program.  The  following  paragraphs 
are  key  considerations  for  successful  development  and  execution  of  a  PMP: 

1.  Migration  Strategy 

The  PMP  should  support  the  selected  migration  strategy.  Migration 
system/application  selection  should  be  based  on  the  following  factors: 

a.  Functional:  To  be  selected  as  a  migration  system/ 

application,  the  information  system  will  have  to  be  based  on  defined  work 
processes  and  will  have  to  be  based  on  the  degree  to  which  the  system  meets  the 
information  needs  of  users  within  and  across  functional  areas.  A  decision  should 
be  generally  supported  by  the  functional  user  community  representing  project 
stakeholders. 

b.  Technical:  The  system/application  can  evolve  (migrate)  to 
be  supported  by  the  DoD  Technical  Architecture  Framework  for  Information 
Management  (TAFIM).  Each  of  these  systems/applications  must  be  integrated 
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into  the  Defense  Information  Infrastructure  (DII)  Common  Operating  Environment 
(COE)  and  Common  Data  Environment  (CoDE). 

c.  Programmatic:  Office  of  Naval  Research  will  undoubtedly 
require  a  functional  economic  analysis  that  documents  a  reasonable  range  of 
alternatives  that  meet  both  functional  and  technical  objectives.  The  alternatives 
must  be  within  programmatic  constraints  (resources,  schedules,  and  acquisition 
strategy),  and  justify  adopting  the  migration  system/application  for  the  community. 
The  migration  system/application  selection  can  be  based  on  an  abbreviated 
functional  economic  analysis. 

d.  Data:  The  ability  to  transition  to  data  standards  is  a 
fundamental  requirement  for  an  information  system  in  order  for  it  to  be  selected  as 
a  migration  system.  Applications  should  lend  themselves  to  data  sharing  within 
their  design.  Migration  plans  must  include  transition  to  commercial  industry 
standard  data  and  shared  data  concepts. 

2.  Project  Strategy 

The  PMP  should  support  the  program  strategy  that  will  be  used  to  design, 
develop  and  deploy  the  SEANET  project,  e.g.,  grand  design,  incremental, 
evolutionary  or  other.  In  selecting  the  appropriate  strategy,  the  unique 
circumstances  of  individual  programs  should  be  considered  and  the  strategy 
chosen  must  remain  consistent  with  the  project's  acquisition  policy. 
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a.  In  determining  which  activities  apply  to  each  increment,  the 
key  question  to  be  answered  is:  what  are  the  objectives  of  the  increment?  From 
this  point,  more  detailed  planning  would  be  required.  Define  each  system 
increment  in  terms  of  the  requirements  it  will  meet  and  its  composite  hardware, 
software,  and  data  base  components.  To  be  useful,  an  increment  should  conform 
to  the  following  rules: 

(1)  Satisfy  a  subset  of  the  requirements  to  be  met  by  the 

complete  system. 

(2)  Constitute  an  entity  that  can  be  used  to  demonstrate  to 
the  customer  that  a  functional  subset  of  the  requirements  has  been  met. 

(3)  Represent  a  logical  division  of  the  design  of  one  or 
more  increments  or  builds. 

(4)  Provide  a  solid  core  for  meeting  the  requirements 
assigned  to  the  remaining  builds. 

b.  Successful  execution  of  an  incremental  or  evolutionary 
program  strategy  requires  a  number  of  changes  to  relationships  and  practices 
common  to  more  conventional  or  "grand  design"  programs: 

(1)  The  need  for  a  closer,  interactive  set  of  relationships 
among  the  functional  user,  the  developer,  the  independent  evaluator,  and  the 
supporter. 
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(2)  The  need  for  streamlined  procedures  to  allow  each 
increment  of  capability  to  progress  rapidly  through  definition,  design, 
development,  testing,  fielding,  operational  evaluation  and  integration  into  the 
operational  environment. 

3.  Software  Metrics 

Software  metrics  provide  a  quantitative  framework  from  which  to  evaluate 
and  control  software  development  or  integration  and  may  be  divided  into  three 
general  categories:  management,  requirements,  and  quality. 

a.  Management  metrics  are  measures  that  help  determine 
progress  against  the  plan.  Trends  in  management  metrics  support  forecasts  of 
future  progress,  early  trouble  detection,  and  realism  in  plan  adjustments. 

b.  Requirements  metrics  pertain  to  specification,  translation,  and 
volatility  of  requirements. 

c.  Quality  metrics  deal  with  testing  and  other  software  technical 
characteristics. 

A  common  core  set  of  management  metrics  for  software  should  be 
developed  early  in  the  development  cycle. 
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VI.  PROJECT  MANAGEMENT  PLAN  FORMAT 


A.  INTRODUCTION 

This  chapter  provides  the  SEANET  Project  participants  with  a  format  to 
develop  a  plan  to  provide  management  control  over  their  activities.  This  will  assist 
the  project  members  in  meeting  cost,  schedule,  and  performance  objectives.  This 
should  prove  helpful  to  the  project  as  they  recently  received  funding  to  pursue 
their  objectives  in  establishing  connectivity  for  mobile  platforms  (research  vessels 
underway  at  sea)  with  the  terrestrial  Internet. 

B.  SEANET  PROJECT  MANAGEMENT  PLAN  FORMAT 

1.  Purpose 

State  the  purpose  of  the  Seanet  Project  Management  Plan  (PMP). 

2.  Objectives,  Scope,  and  Major  Activities 

A  brief  description  and  statement  of  purpose  of  the  SEANET  Project  being 
developed  or  acquired.  Reference  SEANET  Mission  Need  Statement. 

3.  Organizational  Responsibilities  and  Relationships 

Identify  the  management  team/staff,  acquisition  agent,  other  support 
organization  elements  and  contracts  that  support  the  effort.  Reference  the 
SEANET  Project  Manager's  Charter. 
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4.  Management  Approach 


Summarize  all  major  tasks  to  be  performed,  program  management  structure, 
approach,  stakeholders,  schedule,  and  required  resources. 

5.  Migration  Strategy 

Summarize  factors  for  selection: 

1.  Indicate  how  the  proposed  system  will  support  the  "to  be"  work 
processes  and  the  degree  to  which  it  meets  the  information  needs  of 
users  within  and  across  functional  areas. 

2.  Indicate  how  the  implementation/deployment  of  the  proposed  system 
will  ensure  compatibility  with  components  of  by  the  Information 
Infrastructure  and  the  Operating  Environment. 

3.  Summarize  alternatives  that  meet  both  functional  and  technical 
objectives,  and  are  within  programmatic  constraints  (resources, 
schedules,  and  acquisition  strategy).  Justify  adopting  the  selected 
migration  system. 

4.  Indicate  the  ability  to  transition  to  data  standards,  and  show  how 
applications  lend  themselves  to  data  sharing  within  their  design. 

6.  Acquisition  Strategy  for  Migration  Systems 

Summarize  acquisition  considerations  for  selection: 

1.  Indicate  how  existing  Information  Systems,  peripherals  or  other 
assets  in  place  will  be  used  to  support  the  proposed  migration 
system. 

2.  Describe  existing  indefinite  delivery  and  indefinite  quantity  (IDIQ) 
or  other  contracts  that  will  be  used/considered  to  satisfy 
requirements  that  cannot  be  met  through  existing  assets. 

3.  Identify  existing  contracts  for  the  system,  when  awarded,  and  any 
issues  involving  awards. 
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4.  Identify  any  potential  acquisition  issues. 

5.  Describe  the  level  of  proprietary  technology  and  related  impacts  to 
the  SEANET  project. 

6.  Indicate  whether  existing  contracts  contain  language  requiring  the 
use  of  data  standards  and  the  use  of  Enterprise  Data  Model 
structures. 

7.  Defense  Information  Infrastructure 

Describe  how  the  proposed  system  will  support  the  level  of  integration 
required.  Indicate  how  the  proposed  system  will  evolve  to  be  supported  by  the 
integrated,  standards-based  architecture  prescribed  for.  This  is  important  since  the 
oceanographic  fleet  might  need  to  communicate  and  integrate  with  defense  or 
government  agencies  such  as  the  U.S.  Coast  Guard  that  also  use  standards-based 
architectures. 

8.  Program  Strategy 

Present  the  appropriate  program  strategy  that  will  be  used  to  design, 
develop,  and  deploy  the  Information  System.  A  discussion  of  the  grand  design, 
incremental,  evolutionary  and  other  program  strategies  is  contained  in  this  DOD 
Acquisition  Deskbook  (Defense  Acquisition  Deskbook,  1997). 

9.  Data  Standards 

Indicate  the  ability  to  implement  standard  data  structures  (models  as  well  as 
data  standards),  and  how  applications  lend  themselves  to  data  sharing  within  their 
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design.  The  following  are  sample  considerations  for  determining  data  migration 
and  standardization  feasibility. 

1.  Indicate  if  and  how  data  are  separated  from  applications  (e.g.,  use  of 
APIs,  DBMSs). 

2.  Indicate  the  extent  to  which  the  Information  System  is  modeled 
(logical  and  physical).  If  both  logical  and  physical  models  exist, 
indicate  whether  they  are  mapped  to  each  other  and  in  what  tool. 

3.  Indicate  whether  the  migration  system  logical  data  model  is  mapped 
to  the  SEANET  Enterprise  Data  Model  and  the  extent  to  which  the 
migration  Information  System  uses  standard  data  and  implements 
Enterprise  models. 

4.  Indicate  to  what  extent  the  data  elements  (standard  and  non¬ 
standard)  are  registered  in  a  Data  Repository  (DR),  and,  if 
applicable,  whether  the  system  is  registered  as  a  user  of  the  standard 
data  elements  in  the  DR.  For  Information  System  using  non¬ 
standard  data  elements  and  structures,  indicate  whether  a  data 
migration  strategy  exists  and,  if  so,  is  documented  and  approved  in  a 
Project  or  Functional  Data  Administration  Strategic  Plan  (DASP) 
Action  Plan(s)  (if  so,  attach  appropriate  extracts  from  the  DASP). 

5.  Indicate  the  extent  to  which  data  are  shared  with  other  applications 
both  received  from  as  well  as  provided  to  other  applications).  Where 
data  is  shared  with  other  applications,  indicate  whether  documented 
translations  exist  and  where  they  are  recorded  (e.g.,  repository, 
system  code,  etc.). 

10.  Metrics 

Identify  a  common  core  set  of  management  metrics,  considering  key 
measures  such  as: 

1 .  Schedule  and  Progress  -  regarding  completion  of  program 
milestones,  significant  events,  and  individual  work  items. 
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2.  Growth  and  Stability  -  regarding  stability  of  required  functionality  or 
capability  and  the  volume  of  software  delivered  to  provide  required 
capability. 

3.  Funding  and  Personnel  Resources  -  regarding  the  balance  between 
work  to  be  performed  and  resources  assigned  and  used. 

4.  Product  Quality  -  regarding  the  ability  of  delivered  product  to 
support  the  user's  need  without  failure,  and  problems  and  errors 
discovered  during  testing  that  result  in  the  need  for  rework. 

5.  Software  Development  Performance  -  regarding  the  developer's 
productivity  capabilities  relative  to  program  needs. 

6.  Technical  Adequacy  -  regarding  software  reuse  and  use  of  approved 
standard  data  elements. 

11.  Schedule 

Provide  time  schedules  for  accomplishing  tasks. 

12.  Resource  Requirements 

Identify  resources  required  to  support  the  development  effort. 

1.  Manpower.  Summarize  target  and  projected  manpower 

requirements. 

2.  Funding.  Summarize  target  and  projected  funding  requirements. 

13.  Risk  Management 

Identify  any  special  needs  or  characteristics  that  could  represent  areas  of 
risk.  For  example,  identify  any  needs  for  new  technology  development,  and 
schedule  dependencies  external  to  the  program's  control,  and  any  special  skills 
required  to  perform  the  work. 
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1.  Identify  any  risks  that  may  have  a  potential  impact  on  program 
performance,  cost  and  schedule. 

2.  Prepare  a  profile  for  each  risk  including:  probability,  cost  impact, 
schedule  impact,  earliest  expected  visible  symptom,  and  action 
plan(s)  to  be  invoked  upon  detection. 

3.  Update  and  monitor  risk  plans  to  account  for  new  potential  and 
manifest  risks. 

C.  CONCLUSION 

The  establishment  of  a  Project  Management  Plan  (PMP)  is  critical  to 
ensuring  that  the  project  can  meet  its  baseline  goals.  Without  such  a  plan  there 
will  be  no  control  measurement  to  objectively  determine  when  or  if  the  project  is 
meeting  cost,  schedule,  or  performance  goals.  Furthermore,  a  PMP  can  alert 
project  members  quickly  when  critical  aspects  of  the  project  create  a  risk  that 
impacts  the  entire  project.  Management  controls  enable  the  project  members  the 
opportunity  to  make  informed  judgments  in  reducing  risk  and  making  adjustments 
to  ensure  the  project  goals  are  met  as  originally  planned.  The  SEANET  Project  is 
currently  organized  as  a  collaborative  effort.  Therefore,  a  SEANET  PMP  should 
be  developed  and  agreed  upon  by  all  participants  to  ensure  success.  There  is  no 
value  in  developing  a  plan  that  will  not  be  followed.  The  SEANET  project  is  at  a 
point  in  the  life-cycle  that  provides  for  a  natural  way  for  such  a  plan  to  be 
developed  and  for  someone  with  credibility  and  authority  to  be  designated  as  the 
proponent  of  that  plan.  The  SEANET  project  already  has  had  to  adjust  their 
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schedule  due  to  external  funding  delays.  This  is  a  very  reactive  position  to  be  in. 
A  PMP  would  assist  in  identifying  project  problems  so  the  project  participants  can 
take  corrective  action  quickly  to  ensure  the  project  is  kept  on  track. 
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VII.  SUMMARY 


A.  THESIS  SUMMARY 

The  Internet  has  transformed  and  continues  to  transform  eveiy  human 
endeavor.  Commercialization  of  the  Internet  is  largely  responsible  for  this 
phenomena.  The  Internet  had  proved  to  be  a  case  of  how  a  limited  purpose 
technology  evolves  into  a  technology  with  global  impact.  This  occurred  by 
government  funding  and  nurturing  research  and  development  and  transferring  that 
technology  into  the  commercial  sector.  The  market  based  commercial  sector 
through  competition  proves  to  increase  efficiency,  improves  quality,  and  provides 
goods  and  services  at  attractive  prices. 

There  are  still  many  areas  of  the  Internet  that  require  improvement  and 
enhancements  to  meet  and  exceed  user's  requirements.  One  area  is  involves  the 
concept  of  "ubiquitous  computing  and  communication."  Many  areas  of  the  globe 
do  not  have  access  to  the  wired  Internet  due  to  their  physical  location  on  the  globe 
or  due  to  lack  of  infrastructure  that  to  support  Internet  access.  Generally,  these 
areas  are  at  sea  away  from  the  coastlines  of  developed  countries,  on  land  in  remote 
or  undeveloped  areas,  or  in  space.  People  everywhere  are  beginning  to  expect  to 
have  Internet  access  wherever  and  whenever  they  are. 
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The  SEANET  Project  is  an  attempt  to  provide  Internet  access  to  remote 
users  not  connected  to  the  wired  Internet.  It  took  the  wired  Internet  26  years  to 
become  mature  enough  and  cost  efficient  enough  to  transition  to  the  commercial 
Internet.  Once  the  Internet  went  commercial  the  uses,  applications,  and  demand 
for  access  has  increased  at  amazing  rates.  Unlike  the  developers  of  the  Internet, 
the  SEANET  project  does  not  have  the  luxury  of  26  years  to  mature  and  evolve 
their  technology.  Users  now  have  higher  expectations  of  using  the  Internet  when 
and  where  they  want. 

This  research  explored  how  the  SEANET  project  can  more  effectively 
expand  availability  of  remote  access  to  the  Internet  to  meet  users  demands.  It  did 
so  by  using  the  evolution  and  transition  of  the  ARPANET  from  a  military  project 
for  command  and  control  of  strategic  nuclear  forces  to  the  present  day  Internet  to 
understand  lessons  learned  that  should  apply  to  the  SEANET  project.  This 
research  also  described  a  way  for  the  SEANET  project  to  better  achieve  its  goals 
through  the  adoption  and  implementation  of  a  project  management  plan.  The 
SEANET  Project  is  still  in  the  early  stages  of  designing  its  system.  A 
comprehensive  plan  should  better  define  project  participants  roles,  should  foster 
better  communication  and  an  understanding  among  all  participants  of  what  and 
why  they  are  building  this  network,  and  it  should  provide  the  framework  for  the 
project  to  better  adapt  to  changing  requirements.  Using  an  IPT  approach  to 
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develop  the  plan,  a  set  of  management  controls  and  milestones  should  ensure  the 
project  meets  its  objectives.  Should  the  project  participants  determine  they  are  not 
meeting  their  objectives,  they  can  more  quickly  adjust  their  scope.  The  PMP 
developed  can  act  as  a  framework  that  the  project  participants  use  throughout  the 
project  life-cycle  to  plan  execute,  control  and  adjust  their  activities. 

B.  RECOMMENDATIONS 

There  are  four  major  recommendations  that  resulted  from  this  author's 
research.  These  recommendations  are  taken  from  their  successful  use  in  other 
projects  as  reflected  in  the  lessons  learned  from  the  Internet  evolution  or  from 
practices  utilized  in  both  government  and/or  commercial  project  management 
disciplines.  The  recommendations  provide  a  way  to  enhance  the  effectiveness  of 
developing  a  wire-less  capability.  The  following  provides  a  way  to  organize  these 
recommendations. 

1.  Use  the  Lessons  Learned  that  Apply  to  SEANET 

•  Continue  to  use  the  IPT  approach  and  actively  seek  the  participation 
in  and  feedback  from  all  stakeholders. 

•  Develop  a  fielding  plan. 

•  Develop  an  operational  network  but  maintain  a  grand  design  or 
architecture  based  outlook. 

•  Enable  access  to  project  documentation. 

•  Develop  management  controls. 
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2.  Develop  a  Strategic  Vision 

•  Provide  an  understanding  of  what  the  project  wants  as  a  result  that 
captures  the  emotions  of  project  participants  and  possible  users. 

•  Create  an  environment  that  attracts  quality  people  and  organizations 

•  Review  and  update  the  management  style  and  organization  so  the 
appropriate  approach  is  used  through  the  entire  project  life-cycle 

3.  Implement  a  Project  Management  Plan 

•  Assign  a  project  manager  with  proven  experience  and  credibility. 

•  Develop  a  formal  PMP  during  the  upcoming  design  reviews  utilizing 
the  framework  provided. 

•  Develop  clear  roles  and  expectations  for  each  project  participants. 

•  Develop  a  migration  strategy  early  that  transitions  project  through 

different  project  life  cycle  phases. 

•  Establish  a  statistical  control  plan  for  cost,  schedule,  and 
performance  goals. 

•  Develop  consequences  for  not  meeting  cost,  schedule  and 
performance  goals. 

4.  Develop  a  Marketing  Plan 

•  Assign  responsibilities  to  market  the  project  to  attract  people,  ideas 
and  funding. 

•  Conduct  a  demonstration  at  an  internationally  recognized  computer 
communications  symposium  to  motivate  participants  to  achieve  a 
certain  capability  by  a  certain  time  and  to  generate  broad  interest  in 
the  project. 
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The  SEANET  project  has  immense  possibilities  to  impact  all  human 
endeavors  to  an  even  greater  extent  than  the  Internet.  There  are  opportunities  to 
enhance  the  effectiveness  of  the  project  with  a  more  structured  approach  to  the 
planning  and  control  of  the  project. 

C.  FURTHER  RESEARCH 

The  SEANET  project  is  seeking  to  solve  a  problem  for  the  oceanographic 
research  fleet.  Elowever,  the  solution  has  benefit  to  many  different  user  both 
commercial,  governmental,  and  private.  There  are  many  areas  and  disciplines  that 
can  be  explored  to  benefit  this  project  and  to  link  application  to  other  human 
endeavors. 

1.  What  organizational  staffing  considerations  are  there  that  would 
enhance  the  SEANET  Project? 

2.  What  considerations  should  there  be  made  to  test  and  evaluate  the 
project  through  the  entire  project  life-cycle? 

3.  What  logistical  support  considerations  need  to  made  to  implement 
and  support  the  project? 

4.  What  are  the  implications  to  the  project  regarding  manufacturing  and 
production  planning? 

5.  What  contract  types  by  phase  enhance  the  project  as  it  evolves  and 
transitions  to  the  commercial  sector? 
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APPENDIX.  ACRONYMS  AND  ABBREVIATIONS 


ANS 

ARPA 

BITNET 

CoDE 

COE 

CREN 

CSNET 

DARPA 

DII 

DNS 

DOD 

EV 

FTP 

IBM 

ICCC 

IDIQ 

IMP 

INWG 

IPT 

IPTO 

IPv6 

ISP 

JOI 

LAN 

LDEO 

LEO 


Advanced  Network  Systems 
Advanced  Research  Projects  Agency 

Because  It's  Time  Network 

Common  Data  Environment 
Common  Operating  Environment 
Computer  Research  Engineering  Network 
Computer  Science  Network 

Defense  Advanced  Research  Projects  Agency 
Defense  Information  Infrastructure 
Domain  Main  Server 
Department  of  Defense 

Earned  Value 

File  Transfer  Protocol 

International  Business  Machines 

International  Conference  on  Computing  Communication 

Indefinite  Delivery  and  Indefinite  Quantity 

Integrated  Message  Processor 

International  Network  Working  Group 

Integrated  Process  Team 

Information  Processing  Techniques  Office 

Internet  Protocol  version  6 

Internet  Service  Provider 

Joint  Oceanographic  Institute 

Local  Area  Network 
Lamont-Doherty  Earth  Observatory 
Low  Earth  Orbital 
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NCP 

NIC 

NOC 

NPS 

NRaD 

NREN 

NSF 

Network  Control  Protocol 

Network  Information  Center 

Network  Operations  Center 

Naval  Postgraduate  School 

Naval  Research  and  Development 

National  Research  and  Education  Network 

National  Science  Foundation 

OSI 

Open  System  Interconnection 

PDRR 

PM 

PMP 

Program  Definition  and  Risk  Reduction 

Project  or  Product  Manager 

Project  or  Product  Management  Plan 

RFC 

RFP 

Request  For  Comments 

Request  For  Proposal 

SCN 

SDP 

SMTP 

SNMP 

SRI 

Shipboard  Communications  Node 

System  Development  Plan 

Simple  Mail  Tool  Protocol 

Simple  Network  Management  Protocol 

Stanford  Research  Institute 

TAFIM 

TCP/IP 

T1 

T3 

Technical  Architecture  Framework  for  Information  Management 
Transmission  Control  Protocol  /  Internet  Protocol 
a  dedicated  line  that  can  carry  1 .544  megabits  per  second 
a  dedicated  line  that  can  carry  44.736  megabits  per  second 

UCLA 

UCSB 

University  of  California  at  Los  Angeles 

University  of  California  at  Santa  Barbara 

WAIS 

WHOI 

WWW 

Wide  Area  Information  Services 

Woods  Hole  Oceanographic  Institute 

World  Wide  Web 
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